When two .meta/.bin pairs resolve to the same (seg_index, stream_name), the reader currently raises a bare KeyError that names neither of the colliding files nor any of the causes. This same error has surfaced repeatedly across #1606, #1656, #1511, #1782, and for ome IBL files where thre was intentional tamper with the files. Users have no way to self-diagnose. This PR extracts a small helper, _build_signals_info_dict, that owns the dict construction and raises a ValueError naming both colliding .meta paths and listing the four known causes. Behavior is unchanged on the happy path. I have kept the scope tight to the error message and the extraction that makes it unit-testable without .bin fixtures, which the two new tests exercise directly.

Before:

KeyError: "key (0, 'imec0.ap') is already in the signals_info_dict"

After:

ValueError: Two SpikeGLX file pairs resolve to the same stream 'imec0.ap' in segment 0:
  1) /path/to/first.meta
  2) /path/to/second.meta
This can happen if:
  - Files were renamed on disk. Stream names come from the 'fileName' field inside the .meta, not the filename on disk.
  - Recordings from different sessions are in the same folder with the same gate/trigger numbers.
  - Duplicate copies exist in subfolders (the reader scans recursively).
  - A third-party tool rewrote the .meta file with an incorrect 'fileName' (for example, LF meta pointing to the AP binary).

This PR does not close any open issue. The underlying causes behind #1606, #1656, and #1782 are already fixed; the collision remains reachable for #1511 (mixed tcat/non-tcat) and the IBL case, and those require separate fixes. The value here is diagnostic: when any future collision occurs, users and maintainers get enough information to triage it from the traceback alone instead of filing another issue about the same terse KeyError.